In the operation of modern computerized database systems, it has been conventional to provide for certain automated actions such as commitment or manipulation of data and prompt display as a function of user interaction and data input. For example, a particular response to a yes/no field of a screen panel (also called a form) might automatically invoke a display of next permissible actions on the database or data from another table not previously visible, or commitment of such related data. The intent was to provide a facility whereby alerts could be provided back to the user and whereby procedures may be invoked to manipulate data independently of that being input.
Thus, a technique began to appear in commercial computerized database products employing capabilities often called triggers which, in turn, might invoke procedures. Representative examples of this technology may be better understood in greater detail with reference to the commercial database products "Oracle", "Informix" and "SQL Server" (Ashton-Tate/Microsoft) and their associated respective support documentation and publications such as the following:
Oracle SQL*Forms Designer's Reference, Version 2.0, Copyright 1987, Part No. 3304-V2.0, pp 8-2 to 9-34.
Informix-SQL Relational Database Management System User Guide, Copyright 1987, Version 2.10, Part No. 200-404-1015-0 Rev. A, Chapter 6 "Creating Your Own Forms"--Attributes.
Ashton-Tate/Microsoft Learning Transact-SQL, Copyright 1989, Chapter 14, "Creating Triggers".
These materials and database software are published by and available from Oracle Corp., Belmont, Calif.; Informix Software, Inc., 4100 Bohannon Drive, Menlo Park, Calif. 94025; Ashton-Tate Corp., Microsoft Corp., and Sybase, Inc., c/o Ashton-Tate Corporation, 20101 Hamilton Avenue, Torrance, Calif. 90502-1319.
Essentially, in accordance with such techniques, a form or panel could be monitored in a predetermined and specified fashion to detect entry before or after a query or change was executed, when an exit was performed or keystroke was actuated, or the like. Upon detection of such a state which activated a trigger, various functions required by the needs of the database user could be performed. These functions might include, for example, data validation such as range-checking for one of the fields, or the like as desired. While this trigger technique did offer significant improvement in database technology, there were nevertheless deficiencies.
First, the trigger was typically limited in being activated by a few relatively simple preset conditions. Thus it was not able to monitor a complex or complete state of a panel including multiple fields as desired, detect complex functional interrelationships between fields, or perform calculations with multiple fields for purposes of initiating procedures.
Accordingly, the primary intent of such triggers as previously indicated was to serve as alerts or prompts to the data enterer, as, for example, in indicating incorrect entry or a next available set of choices. Additionally, the further primary intent was to start procedures which might manipulate data independent to that which appeared in the panel.
As a result of this limited intent and function of the prior triggers, the triggers tended to become collections of pre-defined triggers for specific purposes as they arose, each with their own limitations and inability to work together cooperatively. As an example, if a value was changed in a field and a trigger could be defined for the change, the trigger typically could not be automatically initiated by the change being made by another trigger without some operator input. Thus, the panel designer was constrained to the limitations of the available trigger set. As additional trigger needs arose, more pre-set triggers were simply added to the product but the user or application designer had no flexibility in expanding the triggers beyond the discrete number pre-set by the product prior to its execution.
The existing database technology thus exhibited a need for a more flexible improved procedure-panel interaction provided by the subject invention, wherein panel operations are permitted as panel commands in a procedural language utilized to specify the procedures, thereby permitting a panel designer to have complete control of sequencing, error recovery, and the coupling of actions together.
As an example, it might be desirable in response to customer data input on a panel, to automatically call a procedure to check a customer's credit status and then report back dynamically to the data inputter on the panel a type of letter desired to be sent to the customer (i.e., payment request; increase of credit limit; etc.) when meeting only certain criteria, such as the percentage of on-time payments, as a function of multiple particular panel fields.
However, the prior art triggers, as previously indicated, were not capable of monitoring the plurality of fields, interrelating them in accordance with functional relationships, calling panel actions from procedures, and modifying forms to perform these desired tasks.
Moreover, due to this inability of the called procedure to include current panel operations as commands in the procedures and the associated procedural language specifying the procedure, there was no provision for looping logic to effect batch panels in order to obviate the need for user input. There was no provision, for example, for printing panel results or effecting other multiple panel actions based on conditions of fields as determined by procedural logic; bypassing of rows automatically by procedures which the particular application does not desire the user to process; and user specific initialization based on procedure logic and determination of the particular user running the application; such capabilities being afforded by the procedure's knowledge of the values of fields in the input form in accordance with the invention.
These and other problems are overcome by the subject invention which provides an improved panel-procedure interaction facility.